CEDEC2015 Day3 メモとか

概要

メモ

物理ベース時代のライトマップベイク奮闘記

シリコンスタジオの方。

ライトマップの効果

最終出力時まで一貫して効果的。

ワークフローの構築

3ds Max + V-Ray

メンタルレイのノイズが気に入らなかったり時間かかったりなのでV-Ray

これ資料アップされるの待ち遠しいな

生成時のいろんなツールのつぎはぎパイプラインすごくつらそう

正しいライトマップ

V-Rayは物理ベースレンダリング

ライトマップに書き込まれるべき値

GrobalIllumination

間接光による値

＝

間接光による照度

あとDirectionalLightの成分とか見てみて云々

クオリティ

ノイズの低減

ライトマップが適応されているものといないものを明確に分けられている

たとえばロボとかのディフューズはライトマップのデータから引っ張られている(?)

質問してみた

どんな言語とかでツールチェーン組めたら幸せな感じがありますか？

->なんでも。一貫して安定してれば。

なるほど

IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

崖っぷちバスターズでの事例

技術採用プロセスとか。

IoTとは

はい

ネットワークゲームのはなし

2010年代のネットワークゲーム

高速なインタネット

MO/MMO

eSports

スマフォ

常時接続前提のゲームあるよね

環境

3/4G

最低で2MB/sとか

崖っぷちバスターズ事例

シングルプレイ

マルチプレイ

シングルプレイだとWebAPI

マルチプレイ

バトル部分はリアルタイム、4人

Bisqueっていう開発基盤をつかっている

Cocos2Dとかをベースにクロスプラットフォームな

前提としての会社の強み、弱み

Web APIは得意

クラウド利用実績とか

リアルタイムサーバ、クライアントとかの構築はやったことない

目指したこと

・実装スピード重視

・1Room 4player ターン制

・レイテンシ最大1秒

プロトタイプの結果、

クライアントにHostをたて、サーバはメッセージのpub/subに徹するタイプになったぽい

比較検討したもの

polling

Socket.io

MQTT

Platform機能(iOSのやつとか

商用エンジン

インフラ、クライアント、ゲーム性の観点からMQTTを選択

(ここでの)MQTTとは

pub/sub

低速、不安定なネットワークでも動く

軽量

QoSあったり

MQTTの解説

はい

実装について

全体像

MQTTBrokerServerをBattleInstanceServerとして利用

Topic -> Room

Room管理はAPIServer制御

マルチプレイバトル

WebAPIでマッチング

マッチング情報をBrokerServer(BattleInstanceServer)へと転送

Clientの一人がHostになり、SessionMasterとして同期移譲管理

broker

room

c1 c2 c3

(Host)

送信するデータはクライアント側で暗号化してる。

(これクライアント側正当性みたいなのクライアント自発的なやつなので、チートしやすそうだな～～～

暗号化してようが暗号化ロジックはクライアントの中にあってクライアント開ければ暗号化手段はそのまま利用できるんで、

この部分の意味はネットワークとかプロキシとかでの中間変更不可という要素に収まるんじゃなかろうか。

んでクライアントから出たデータをそのままpub/subしちゃうので、

データの正当性判断要因や拒否機構がどこにも無く、かつクライアント群という全員クライアント状態なので、運営がチートに気づけるチャンスがなさそうな気がする、、

もうちょい詳しく書くと、全員クライアントで神視点的なバリデータとか状態変化監視者が不在なので、

誰がどんなデータを出しても、受け取る側はとりあえず正しいと思うしか無くて受け取っちゃう、みたいなところがある。

なんだけどこのゲームの場合必殺技のコスト無視とかそのへんで出そうなくらいで

チートされた場合のダメージと比較して看過してるのかな

守りたいのが公平さなのか自作のシステム堅牢性なのかみたいな話で、

ぶっちゃけひどい目にあうユーザが居ない(PVP要素がない、協力プレイで味方が強い分には問題ない)のであれば、

暗号化でシステム堅牢性に目を向けるだけっていうのはメッチャ健全で良いなあと思った。

)

余談

PhotonがClient-ClientRPCとかをサポートしてて使うのすごく楽なんだけど、あれ使ってクライアント群内にHost作るとかそういう感じに進むと

PvPとかがあるゲームルールによってはチート情報を全クライアントで無条件にSyncしちゃってそれを誰もValidateできずに

最高にキッツイ状態になるので、何事もまずは選択肢増やして使う際に気をつけるべきだなあという感想。

簡単にそういうのできるソリューションを選べると良いな。

Hostが落ちた場合は別のClientに移譲する

これ地味にめっちゃ大変なはず、誰がNext Hostなのかを判断する要素がサーバ側に無いと楽にならないような、、

WebAPI側で解決してたりするのかな。もしかしたらそうおっしゃっていたかもしれない。

質問で聞いてみたかった。

BrokerServerの実装は？

一台あたりの性能、コストを最大化したい

高負荷時の安定性あたりを基準に見ている

MosquittoとRabbitMQ with MQTT Plugin が候補に残った

Mosquitto

シングルスレッド、クラスタリングする場合は自作

RabbitMQ

マルチスレッド、クラスタリングあり <- RabbitMQを選択。

構成案

Broker Standalone parallel

結局パフォーマンス劣化、接続時間のトレードオフなどからクラスタリングせず。

AWSでのオートスケーリングが効く環境を構築して云々

アプリケーション編

クライアントライブラリの実装の話

選定

フルスクラッチ or paho or Mosquitto

ライブラリで使えればいいよねって感じでMosquitto(libmosquitto)を選択。

BSDソケット使ってるんだけどiOS/Androidでいろいろ問題が。

→Mosquittoのコードには手を加えないでいいように工夫(Define置き換えとか)

トピック一覧

Common

ブロードキャスト

System

ブロードキャスト

Host

相互死活判定

ゲストが投げるとHostに集約される

Private/ゲストID

ホストがゲストに対して送付

お互いに送れば擬似P2P

QoS

アニメーション情報とかはQoS0

衝突、必殺技などの必須情報はQoS1

最悪でもQoS1のもののみが届けばゲームが成立するのを想定して振り分けている。

QoS1で送っているものについてはさらに再送をする機構をつけた(?)

これどこでコントロールしてるんだろう。サマーレッスンの時間迫ってたので部屋でちゃった。

データ構造

msgpack

今後はpahoに乗せ換える予定

あとElixirとか試し中

サマーレッスン

整理券失くすとか凄まじいダメさを発揮しつついろいろあって復帰して観れた。感謝しかない。。

箇条書きで

・人と対面する、っていうシーンなんだけど、これ火力あげるには他人の中の自分、みたいなのの表現が必要で、「これスペックとか表現で突破できるものなのかなあ、、超優秀な表現AI、そのグラフィック表現が必要な世界でメッチャ遠そう」みたいな感想。

・臨場感を感じさせるための工夫みたいなのはなんかしっくりこなかった。

・画質はCBのほうがよかったな～と思いつつ。

・ユーザーが何かをしたい、っていうのを引き出す系統ばっかり触ってきたので、そういうタイプじゃないコンテンツだなと思った。PS3の「アフリカ」とかをちょっと思い出す。

自分は「綺麗」っていうパラメータが何かを触る時のモチベーションとして長時間もたないタイプなので、なんか綺麗なだけだとつまらないんだなと思った。

このへんは女子高生のお部屋モードだったら俺の感想は違ったんだろうか。あんま違わない気がする。

VR、「許されるツッコミやすい隙」みたいなのがあれば、想像力の余地の世界、みたいなのがまた発生しそうな予感がある。